Field
Various communication systems may benefit from the transfer of sender or receiver communication parameters. For example, such transfer of sender communication parameters may be useful in connection with single radio voice call continuity (SRVCC) and reverse SRVCC.
Description of the Related Art
Third generation partnership project (3GPP) technical specification (TS) 23.216 and TS 23.237 describe the single radio voice call continuity (SRVCC) procedures that are already standardized in 3GPP. Each of 3GPP TS 23.216 and 3GPP TS 23.237 is hereby incorporated herein by reference in its entirety. Additional SRVCC procedures may be needed to enhance the chances of transcoder-free operation for voice calls after a handover from PS access for voice to CS voice access. Examples of PS access for voice include long term evolution (LTE), where internet protocol (IP) based voice over LTE (VoLTE) is used. Examples of CS voice access include global system for mobile communication (GSM) and universal mobile telecommunications system (UMTS).
An access transfer control function (ATCF) and an access transfer gateway (ATGW) can be used to anchor media. They can be inserted into the session initiation protocol (SIP) signaling and media path, respectively, to avoid the remote peer needing, during a handover, to be updated to inform it about a change of the termination of the IP part of the media path from user equipment (UE) to mobile switching center (MSC) server during a handover.
After a handover, the ATGW may need to modify the transport format and possibly also encoding of user plane packets received from the remote peer even if the codec is not changed. This modification may be needed to adjust to the formats the MSC wants to receive. For instance, the ATGW may need to adjust the real time protocol (RTP) payload type or modify the number of speech samples in a packet.
This need for modification or adjustment may be caused by the fact that, prior to the handover, in session description protocol (SDP) the UE has signaled payload and encoding parameters describing the payload and encoding the UE wants to receive. This information has been forwarded to the remote peer, which has chosen the transport format and encoding the remote peer uses when sending packets accordingly. However, the MSC is not aware which transport formats and encoding parameters the UE has signaled. The MSC may choose different parameters, even if it could also support receiving the transport format end encoding the UE has signaled. To avoid long service interruption during the handover, the remote peer may not be informed via new SDP signaling during the handover about the transport format end encoding parameters the MSC desires to receive.
Conventionally, one option is that the ATCF can update the remote peer via SDP signaling with the transport and encoding parameters provided by the MSC. However, the related SDP offer-answer exchange may take several seconds to complete. During this time, either extra resources at the ATGW are still required as the ATGW still needs to be prepared to receive the payload format as originally requested by the UE, and change the format and encoding to what has been requested by the MSC, as well as the new payload format end encoding requested by the MSC. Otherwise there will be a service interruption.